Celestin Apprentice 5/Apprentice-Release5.iso/Information/THINK C Digest/1991/91-03

Text File | 1995-12-31 | 79KB | 2,102 lines

Path: ucivax!gateway
From: [e-mail] ("David S. McCormick")
Subject: Stack smashing the heap in TCL
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 44
Date: 2 Mar 91 22:32:07 GMT

I am using a dialog subclass of window which accesses STR# and TEXT/styl
resources to create a help window. I am using a  subclass of StaticText
which handles TEXT/styl resources in a ScrollPane. The STR# is read in
just fine.

For the Dialog
itsGopher = this;
so that I can intercept KeyDown's to give the list pane KeyDowns and
subsequently change to a new TEXT/styl resource.
I load these resources depending what item in a scrolling list are
clicked on. I load them with

void    CMyHelpDialog::DoListClick ()
{
CharsHandle        theAboutText;
StScrpHandle    theAboutStyle;

...
theTextH = GetResource( 'TEXT', theID);
theStyleH = GetResource( 'styl', theID);
...
/* put the TEXT/styl in the Panorama */
...
ReleaseResource ((Handle) theTextH);
ReleaseResource ((Handle) theStyleH);
...
}

Anyhow, I intercept the keydowns fine and switch the position in the
list, then load a new TEXT/styl resource to correspond to this change.
After a couple of keydowns, the Mac freezes and when I poke around in
TMON I get the infamous Deep Shit Errors 25 and 28 which means that the
Stack has grown over the Heap and smashed the Heap.
THIS PROBLEM ONLY OCCURS WHEN I BUILD THE APPLICATION; IT WORKS FINE
WHEN IN THE DEBUGGER.

Can anyone give me any clues as to why the stack is suddenly getting so
big?

Many thanks.
Cheers,
David S. McCormick
MIT-EAPS Geology
[e-mail]










Path: ucivax!gateway
From: [e-mail] ("David S. McCormick")
Subject: Stack smashing the heap in TCL
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 44
Date: 2 Mar 91 22:37:22 GMT

I am using a dialog subclass of window which accesses STR# and TEXT/styl
resources to create a help window. I am using a  subclass of StaticText
which handles TEXT/styl resources in a ScrollPane. The STR# is read in
just fine.

For the Dialog
itsGopher = this;
so that I can intercept KeyDown's to give the list pane KeyDowns and
subsequently change to a new TEXT/styl resource.
I load these resources depending what item in a scrolling list are
clicked on. I load them with

void    CMyHelpDialog::DoListClick ()
{
CharsHandle        theAboutText;
StScrpHandle    theAboutStyle;

...
theTextH = GetResource( 'TEXT', theID);
theStyleH = GetResource( 'styl', theID);
...
/* put the TEXT/styl in the Panorama */
...
ReleaseResource ((Handle) theTextH);
ReleaseResource ((Handle) theStyleH);
...
}

Anyhow, I intercept the keydowns fine and switch the position in the
list, then load a new TEXT/styl resource to correspond to this change.
After a couple of keydowns, the Mac freezes and when I poke around in
TMON I get the infamous Deep Shit Errors 25 and 28 which means that the
Stack has grown over the Heap and smashed the Heap.
THIS PROBLEM ONLY OCCURS WHEN I BUILD THE APPLICATION; IT WORKS FINE
WHEN IN THE DEBUGGER.

Can anyone give me any clues as to why the stack is suddenly getting so
big?

Many thanks.
Cheers,
David S. McCormick
MIT-EAPS Geology
[e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: Re: class declarations
Original-From: attmail!ehorvath (Ned Horvath )
Lines: 82
Date: 4 Mar 91 01:52:40 GMT
Phone: [phone]
Message-ID: <[e-mail]>
In-Reply-To: your message <internet0590007030> of Wed Feb 27 21:26:10 GMT 1991
>To: internet!ics.uci.edu!think-c
Content-Type: text
Content-Length: 3338
Newsgroups: fa.think-c
Message-Version: 2
EMail-Version: 2
UA-Message-ID: <MAC-1.3.2-618034-ehorvath-254>
UA-Content-ID: <MAC-1.3.2-618034-ehorvath-254>
MTS-Message-ID: <ehorvath0630027101>

Garth Dickie writes,
> I am writing a class library for TC4; I want to experiment with some stuff
> which doesn't fit into the TCL.  This question has to do with the way I
> create objects from resource templates.

>The idea is to correlate an integer with every class which may be
> instantiated from a template.  Then that integer is translated at runtime
> into a void*, which can be passed to new to get an object of the appropriate
> type.  What I *don't* want to do is a switch with one line per class, or
> similar kludery.
...

If Garth's the only person interested in this kind of elegant hack, please
forgive posting to the list.  But I suspect there's more than one person out
there who's interested...

The following file compiles clean for me (I copied it directly from the ThC
source window, so I KNOW it's clean):

------- Cut here ----------
#define ctabEntry(name,restype)        { #name, restype, name }

typedef struct classTab {
    char *        className;
    ResType        classResType;
    void *        classSpec;
} classTab;


#include <CPanorama.h>
#include <CPane.h>
#include <CBureaucrat.h>

classTab myTab[] = {
    ctabEntry (CPane, 'Pane'),
    ctabEntry (CBureaucrat, 'Buro'),
    ctabEntry (CPanorama, 'Pano'),
    {0,0,0}
};
------- End Cut ------------

A bit of explanation.  The ctabEntry macro exploits an ANSI-ism, namely
        #param becomes "paramvalue"
when the macro is expanded.  This lets you type each class name once, and the
string constant is guaranteed to match the type name.  This is a nice
typecheck: to see that ThC will catch an error, try adding
        ctabEntry (CBogus, 'hah!'),
to the myTab definition.

Anyway: each classTab entry contains the name of the class as a string
constant; the resource type you want to associate with the class; and the
void* that bless(obj,classtype) wants for its second argument.

An aside: please excuse the use of CBureaucrat; that's an abstract class that
you'll never instantiate, let alone save as a resource, but you could if you
wanted to...

This table now admits of lookup based on any of several criteria; I'm tempted
to expand it into a full-blown class definition myself.  Some of the
operations you might perform with a table like this are
        - look up the resource type associated with a given class by name.
        - look up resource type given class by void*.
        - look up resource type given an instance of the class.
        - look up class type given a resource type.
        - look up class type given a resource.
        - a replacement for LoadResource, but returning a blessed object.
        - a replacement for CreateResource, but taking an object as argument.

One of the objections Garth raises to this approach is that the classTab has
to be recompiled whenever any of the class interface headers changes.  That's
perfectly true, but personally, I couldn't care less: it's a small price to
pay, and ThC will take care of it for me.  Notice that the rest of what he was
after -- only one source file to maintain, and the linker does most of the
work -- are satisfied by this approach.  You still need to write the lookup
procedures.

Is that the kind of thing you had in mind, or have I missed your intent
entirely?  Anyway it was fun to think about, so thanks for the stimulation...

=Ned Horvath=
[e-mail]
[e-mail]










Path: ucivax!gateway
From: [e-mail] ("David S. McCormick")
Subject: Re: Stack smashing the heap in TCL
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 4 Mar 91 13:35:16 GMT

As [e-mail] pointed out, I did not indicate which machine I was
running on when all the excitement occurred. I am using an SE/30 running
sys 6.0.7 with 8 mb RAM under Multifinder with the default application
memory size of 384k.

Thanks,
David S. McCormick
MIT-EAPS Geology
[e-mail]










Path: ucivax!gateway
From: [e-mail] ("David S. McCormick")
Subject: Where to intercept clicks to allow different panes to communicate within same window?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 4 Mar 91 19:57:03 GMT

I have a window which contains several panes which need to communicate.
I have a scrolling list pane and a static text in a scroll pane to
display some TEXT resources. When the list is clicked on, a particular
TEXT resource is loaded into theTextPane. I have gotten this to work by
having a list method SetCmdClick() which is the same that for CButton,
so that when the DoClick() method is invoked for the list, itsSupervisor
gets a DoCommand() message afterward. Is there a more
politically-correct TCL way to do this? It's easy to override the
DoKeyDown() method for a Document or Director to dispatch KeyDown's, but
the document can's normally dispatch clicks. Should I declare a subclass
of Window to allow it to dispatch clicks?

Any help appreciated.

Cheers,
David S. McCormick
MIT-EAPS Geology
[e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: Sharing Classes Between Projects
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Original-From: j.a.brownlee
Lines: 32
Date: 5 Mar 91 14:16:07 GMT

I have some classes that I would like to share between several projects.  The
classes aren't generally useful for any type of project -- they are only useful
across a suite of applications I am developing.

Sharing the .c files is easy, but I am having trouble coming up with a good
way to share the .h files.  I would like a method that does not require a
complete re-work if I move the entire directory structure to a new location.

Here is what I have thought of:

   .    Put the stuff in the THINK C tree.  I would like to avoid this if
    possible, but this is probably my fall back solution.

   .    Use some sort of relative pathname in the #include statements, like
    using "../file.h" under UNIX.  Is there a way to do this?

   .    Use a #define in each project to define the desired include directory,
    then use statements like:

        #include MY_INCLUDE_DIR ## "file.h"

    (does this even work?)  This is crummy because if I move the include
    directory, I have to edit a file in every project.

I'm sure someone out there has run into this problem before, so I am interested
in hearing any solutions you have tried.  E-mail if you like, but I think that
this topic would interest many list subscribers.

   -      _   Joe Brownlee, Analysts International Corp. @ AT&T Network Systems
  /_\  @ / `  471 E Broad St, Suite 1610, Columbus, Ohio 43215   [phone]
 /   \ | \_,  E-mail: [e-mail]     Who pays attention to what _I_ say?
 "Scotty, we need warp drive in 3 minutes or we're all dead!" --- James T. Kirk










Path: ucivax!gateway
From: [e-mail] (Michael McGuffey)
Subject: anyone know where i can find Spinside Macintosh?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 20
Date: 5 Mar 91 16:40:22 GMT
X-Envelope-to: [e-mail]


I've been looking around for the electronic version of the _Inside Macintosh_
series.  It's not on apple.com.  Judging from the ls-lR on ftp.apple.com,
it's there, but not accessible.  I looked on CompuServe but cannot find it.

I don't really have access to a CD-Rom at this time or I would subscribe to
D E V E L O P.

Anyone have any suggestions?

Also, is _Spinside Macintosh_ a replacement for the 5 volume set or is
that set still recommended?


-----------------------------------------------------------------------------
Michael McGuffey, Director      BITNET:   mcguffey@marshall
Office of Institutional Research  Internet: [e-mail]
Marshall University          Phone:    [phone]
Huntington, WV 25755          FAX:      [phone]
-----------------------------------------------------------------------------










Path: ucivax!gateway
From: [e-mail] (Brain in Neutral)
Subject: Re: Sharing Classes Between Projects
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 53
Date: 5 Mar 91 16:40:51 GMT


>I have some classes that I would like to share between several projects.  The
>classes aren't generally useful for any type of project -- they are only useful
>across a suite of applications I am developing.

>Sharing the .c files is easy, but I am having trouble coming up with a good
>way to share the .h files.  I would like a method that does not require a
>complete re-work if I move the entire directory structure to a new location.

Yes, indeed, so would I.  The method that I am aware of (put the .h files
in current or subfolder) is unhelpful.  It leads to duplication of files
in multiple project folders (a bad idea) or ugly pathname dependencies.
The latter is also a problem for .c files included in projects if you happen
to move the project somewhere else.  Suddenly you have to remove and re-add
some files.

>Here is what I have thought of:

>   .    Put the stuff in the THINK C tree.  I would like to avoid this if
>    possible, but this is probably my fall back solution.

This is what I do for header files.  I have a "local #includes" folder
as a counterpart to "mac #includes" in the THINK C folder.  At least that
way it's marked as not part of the standard distribution.

But I wish there were some sort of project-specific configuration one
could use to duplicate the UNIX cc -I option...

>   .    Use some sort of relative pathname in the #include statements, like
>    using "../file.h" under UNIX.  Is there a way to do this?

    Breaks if you move your project folder somewhere else?

>   .    Use a #define in each project to define the desired include directory,
>    then use statements like:

>        #include MY_INCLUDE_DIR ## "file.h"

>    (does this even work?)  This is crummy because if I move the include
>    directory, I have to edit a file in every project.

Perhaps if there is a project-specific header file that's #included in
every project file, you could put that line in it.  At least that way,
when you move the project, you only have to edit one line.

>I'm sure someone out there has run into this problem before, so I am interested
>in hearing any solutions you have tried.  E-mail if you like, but I think that
>this topic would interest many list subscribers.

It would certainly interest me.

Paul DuBois
[e-mail]










Path: ucivax!gateway
From: [e-mail] ("Russell S. Finn")
Subject: Re: Sharing Classes Between Projects
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 65
Date: 5 Mar 91 20:34:30 GMT

Paul DuBois writes (quoting Joe Brownlee initially):
> >I have some classes that I would like to share between several projects.  The
> >classes aren't generally useful for any type of project -- they are only useful
> >across a suite of applications I am developing.
>
> >Sharing the .c files is easy, but I am having trouble coming up with a good
> >way to share the .h files.  I would like a method that does not require a
> >complete re-work if I move the entire directory structure to a new location.
>
> Yes, indeed, so would I.  The method that I am aware of (put the .h files
> in current or subfolder) is unhelpful.  It leads to duplication of files
> in multiple project folders (a bad idea) or ugly pathname dependencies.
> The latter is also a problem for .c files included in projects if you happen
> to move the project somewhere else.  Suddenly you have to remove and re-add
> some files.

I'm not sure I understand the problem.  If you're working on a related
group of programs, then it doesn't seem unreasonable to place all of
the project files in one folder.  Why isn't the following scheme
satisfactory (indentation represents nesting of folders)?

* Suite Folder
    * App1.proj
    * App1.proj.rsrc
    * App1 Source Folder
        * App1-main.c
        * App1-sub1.c
        * ...
    * App1 Include Folder
        * App1-defs.h
        * ...
    * App2.proj
    * App2.proj.rsrc
    * App2 Source Folder
        * App2-main.c
        * App2-sub2.c
        * ...
    * App2 Include Folder
        * App2-defs.h
        * ...
    * Common Source Folder
        * common-subs.c
        * ...
    * Common Include Folder
        * common-defs.h
        * ...

If there are naming conflicts between application-specific files
(e.g., two "main.c" files), the "App1" folders could be placed in
a project-specific folder called "(App1.proj)", etc.

You need to be careful when creating files, to make sure they go into
the proper folders (a utility like Super Boomerang would be a great
help here), but having done that, you can open your source and include
files directly from the project window, so navigating the hierarchy
shouldn't be a problem.  Since the project files themselves are at the
top level of this hierarchy, all subfolders will be searched for
include files (except, of course, those named with parentheses), so
there shouldn't be any trouble finding them.

Now I've just done this off the top of my head, so maybe I've
overlooked something, but is that what you're looking for?

-- Russell Finn
[e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: Re: Sharing Classes Between Projects
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 4
Date: 6 Mar 91 02:19:40 GMT

Seems to me that using THINK C's parenthesis rule would help here.  All
projects would go in a main folder.  Each project's specific files
would go in its parenthesized subfolder.  The common files would go in
non-parenthesized folders.










Path: ucivax!gateway
From: [e-mail] (Brain in Neutral)
Subject: Re: Sharing Classes Between Projects
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 21
Date: 6 Mar 91 07:07:45 GMT


>I'm not sure I understand the problem.  If you're working on a related
>group of programs, then it doesn't seem unreasonable to place all of
>the project files in one folder.  Why isn't the following scheme
>satisfactory (indentation represents nesting of folders)?

>* Suite Folder
    >* App1.proj
    >* App1.proj.rsrc
    >* App1 Source Folder
    > etc.

If they're related, yes.  But what if the files to which you want
to refer are general enough or of sufficient importance that you want
to use them in *all* your projects, related or not?

E.g., for commonly-included header files, why should I have to care
at all where I put my project, and its folder/subfolders?

Paul DuBois
[e-mail]










Path: ucivax!gateway
From: [e-mail] ("Martin Minow, ML3-5/U26  06-Mar-1991 1010")
Subject: re: sharing classes
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 15
Date: 6 Mar 91 15:21:58 GMT

Of course, what we have here is another instance of multiple-inheritance.

I just duplicate the files, but, hey, I'm lazy.  I think that System 7's
"alias" capability would let you keep one central source code repository
that is visible in multiple folders.  (This assumes, of course, that
the Think compiler handles aliased files correctly, but I don't think
this is a real problem.)

Now, if only I could put my resource source file in the project so
it gets built automatically.

And, if only that resource source was in Rez format so constants were
entered once only.

Martin.










Path: ucivax!gateway
From: [e-mail] ("Russell S. Finn")
Subject: Re: Sharing Classes Between Projects
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 6 Mar 91 19:46:34 GMT

> If they're related, yes.  But what if the files to which you want
> to refer are general enough or of sufficient importance that you want
> to use them in *all* your projects, related or not?

OK, in that case, I agree it's best to just put them in a folder in
your THINK C folder.  I thought the original poster said he was
working on a group of related projects, and had files common to those
projects (but not necessarily applicable outside the group), so I made
my suggestion.

As Martin Minow points out, the use of aliases in System 7 may help
the situation out as well.  (In fact, I can't help thinking that it's
been over a year and a half since THINK C 4.0 came out (hi, Michael),
and while I don't want to start any rumors, wouldn't a System-7-studly
version of THINK C be something to look forward to?)

-- Russ











Path: ucivax!gateway
From: [e-mail]
Subject: Re: Sharing Classes Between Projects
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Original-From: j.a.brownlee
Lines: 10
Date: 7 Mar 91 12:34:48 GMT

Thanks one and all for your comments.  I am going to use the "sub-folder"
method, which seems to meet my needs.  However, as one poster pointed out,
THINK C really needs a dialog something like "cc -I" to specify include
directories.  And while you're at it, how about a "cc -D"-like option to
define global pre-processor symbols, too?

   -      _   Joe Brownlee, Analysts International Corp. @ AT&T Network Systems
  /_\  @ / `  471 E Broad St, Suite 1610, Columbus, Ohio 43215   [phone]
 /   \ | \_,  E-mail: [e-mail]     Who pays attention to what _I_ say?
 "Scotty, we need warp drive in 3 minutes or we're all dead!" --- James T. Kirk










Path: ucivax!gateway
From: [e-mail] (Garth Dickie)
Subject: Re: Rez (Was Re: Sharing classes)
Message-ID: <9103061412.AA00419@macduffe>
Newsgroups: fa.think-c
Lines: 35
Date: 7 Mar 91 14:35:22 GMT

"Martin Minow" <[e-mail]> writes...
>And, if only that resource source was in Rez format so constants were
>entered once only.

This one, at least, does have a solution.  SARez/SADerez is in pub/dts/nerdtools
at ftp.apple.com (not apple.com).  There is no documentation, or header files.
However, somewhere (I forget at the moment) the headers for MPW C, Pascal, and
(bingo!) Rez have been placed for ftp.  I think they are on apple.com.  The SA
versions run as standalone applications, and come up into the standard commando
interface.  When you have set up a command line, you can save it as a SARez
document; thereafter, opening the document launches Rez on that command line,
*without* bringing up the commando interface.  It is not quite as convenient
as having the compiler launch for you from a make, but it is quite a bit better
than using RMaker.  Among other things, you can define your own types...

There is no documentation on the Rez format available for ftp, that I know of,
but there are several sources of information:
 -- the .r headers from MPW
 -- the .r header from the installer 3.0 documentation is more complicated
 -- run SADerez on large resource files and look at the ouput ;-)
 -- run SADerez on the 'STR#' resources in SARez, and read!  This gives you all
    of the possible error messages and tokens.

If you design your headers correctly, you can use them for both C and Rez.
essentially, anything but a #define needs to be bracketed by #ifndef Rez,
#endif directives. (Rez is defined when Rez is running, Derez when Derez is
running, apparently).

Among other things, Rez will compile multiple source files into a single
resource file, process `include` (not #include) statements to include actual
resources from other files, and optionally merge compiled resources into the
destination, rather than creating the destination.

Sorry if this is all well known,
 -- garth










Path: ucivax!gateway
From: [e-mail] (Paco Xander Nathan)
Subject: Sys 6.0.7 SndManager
Message-ID: <9103082046.AA15602@neuromancer>
Newsgroups: fa.think-c
Lines: 21
Date: 8 Mar 91 21:13:47 GMT

So now that system 6.0.7 has the new Sound Manager, does anybody have trap
addresses for the new routines, eg. SndRecord() ???

I've d/l the interim "Sound Manager/Glue" off the DTS section of AppleLink (it's only in an
AppleLink format so there's little use in posting it).  It has the interim Inside Macintosh
rewrite for SndMgr, but it doesn't include trap addresses.

We've been doing some sound work here, and would like to call SndRecord() from ThC.
Anybody seen another SndMgr interface?

Thanks -

paco
----
Internet:        [e-mail]

Cyberspace Development
Motorola, Microprocessors
Austin, Texas, USA

(c)1991, PXN. Subject to Public Law 99-508.  B*B!










Path: ucivax!gateway
From: [e-mail] ("James E. O'Dell")
Subject: Floating point stangeness
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: "James E. O'Dell" <[e-mail]>
Organization: Fort Pond Research
Lines: 36
Date: 9 Mar 91 02:54:34 GMT

I am having trouble with the following short C program...

void main()
{
   double fl;
   while (TRUE)
{
     scanf("%lf", &fl);
     printf("%lf\n", fl);
     }
}

Here's the problem.

Type in 1.0
All is fine I get back 1.0

Type in 1.0e-40
All is fine I get back zero

Type in 1.0e-4000
All is fine get back zero

Now type in 1.0e-50000
I get back INF.

This seems like a bug in either SANE or the way THink C is using it.

I would like to get back zero for 1.0e-50000 also.
Do I have to make a pre-pass on all of my input to accomplish that?
If not how do I get it?

Thanks,
Jim O'Dell












Path: ucivax!gateway
From: [e-mail] (Rob Olsen)
Subject: Mailing list
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 1
Date: 9 Mar 91 13:22:57 GMT

Could you take my name off the mailing list?  Thank you.










Path: ucivax!gateway
From: [e-mail] ("Matthew T. Russotto")
Subject: Re:  Floating point stangeness
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 3
Date: 13 Mar 91 03:57:49 GMT

(-50000) is not in the range of integers, which is probably your limit.  You
might want to change the libraries to use longwords instead, though that
merely extends the limit










Path: ucivax!gateway
From: [e-mail] (Bassel Soudan)
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 57
Date: 13 Mar 91 04:28:22 GMT

Hello fellow mail list patrons,

    I have a problem that I am trying to solve and I need your help.

    The problem has to do with multiple inheritance and goes like this:

    I created a CComponent class to model a hardware component. Each
component is made up of several elements (Panes, Buttons, StaticText etc.).
The elements for the components are grouped together in a List called
itsElements. When my component receives a Draw or Move message, I want to
pass that along to all the elements that make up this component. Here is what I
am doing now :

    In my CComponent::Draw() method I call

    DoForEach->itsElements(DrawElem);

    In DrawElem (CObject *obj)     I try to do the following :

    obj->Draw();            All the elements that make up the
                    components have a Draw message defined.

    When I try to compile this program, I get the famous "Draw is not part
of the struct or union" or something similar to that. I get this because CObject
does not have a Draw method (and it shouldn't).

    What I want to do is create a co-parent class for all the objects that
will be elements in my components, so that I can cast obj into that and solve
the problem. The elements that I am using are all subclasses that I derived
from the original classes. (for example I derived a CField class as a sub-class
of CPane).

    I created a sub-class of CObject and made all my element classes
sub-classes of that class. The only problem is that my element classes no
longer exhibit the behavior of their original parents. (i.e. my CField which
should be working like a CPane is no longer able to perform any of the things
that a CPane can).

    I asked this quetion somewhere else, and somebody suggested that I
create a subclass of CObject (call it Element for now) and then customize
it by pointing to instances of a CPane or a CButtonor or whatever. The only
problem is that my customized instance of CElement will not inherit all the
behavior of the parent class (the one whose instance I am pointing to).

    The whole problem is that I need to cast the entries in the itsElements
list to be able to pass them the Draw message that I got. If anyone knows a way
to bypass this casting requirement, that might solve my problem.

    I am sorry if this has been long and confusing but this is the only
way I could describe the problem. If you can be of any assistance I would be
eternally gratefull.

            Sincerely yours,

            Bassel Soudan

            [e-mail]










Path: ucivax!gateway
From: [e-mail] (Mark Alldritt)
Subject: TCL app's stop Moire cdev
Message-ID: <910312856*[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 13 Mar 91 04:42:41 GMT

I have noticed that when i'm debugging an application which is based on
the THINK-C Class Library the Moire cdev stops.  By stops I mean that the
clock stops, and the screen saver will not start (even when I put the
mouse in the sleep region).  Has anyone else run into this problem, and
is there a fix I can make?

Thanks in advance,

-Mark










Path: ucivax!gateway
From: [e-mail]
Subject: Re: TCL app's stop Moire cdev
Original-From: attmail!ehorvath (Ned Horvath )
Lines: 11
Date: 13 Mar 91 17:30:07 GMT
Phone: [phone]
Message-ID: <[e-mail]>
In-Reply-To: your message <internet0720540070> of Wed Mar 13 04:42:41 GMT 1991
>To: internet!ics.uci.edu!think-c
Content-Type: text
Content-Length: 384
Newsgroups: fa.think-c
Message-Version: 2
EMail-Version: 2
UA-Message-ID: <MAC-1.3.2-618034-ehorvath-299>
UA-Content-ID: <MAC-1.3.2-618034-ehorvath-299>
MTS-Message-ID: <ehorvath0721614060>

>I have noticed that when i'm debugging an application which is based on
>the THINK-C Class Library the Moire cdev stops...

In your CApplication initialization, set gSleepTime to something less than
infinity (the default).

Greg Dow considers this a Moire (and Pyro, and...) bug, and I agree with him,
but we have to live in an imperfect world...

=Ned Horvath=
[e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: Recursive drawing
Original-From: attmail!ehorvath (Ned Horvath )
Lines: 39
Date: 13 Mar 91 17:30:43 GMT
Phone: [phone]
Message-ID: <[e-mail]>
In-Reply-To: your message <internet0720540080> of Wed Mar 13 04:28:22 GMT 1991
>To: internet!ics.uci.edu!think-c
Content-Type: text
Content-Length: 1402
Newsgroups: fa.think-c
Message-Version: 2
EMail-Version: 2
UA-Message-ID: <MAC-1.3.2-618034-ehorvath-300>
UA-Content-ID: <MAC-1.3.2-618034-ehorvath-300>
MTS-Message-ID: <ehorvath0721614120>

[e-mail] (Bassel Soudan) writes:

>        In my CComponent::Draw() method I call

>        DoForEach->itsElements(DrawElem);

>        In DrawElem (CObject *obj)      I try to do the following :

>        obj->Draw();                    All the elements that make up the
                                        components have a Draw message
                                        defined.

>        When I try to compile this program, I get the famous "Draw is not
>part of the struct or union" or something similar to that. I get this because
>CObject does not have a Draw method (and it shouldn't).

Correct.  But it does sound as though each type of element could be a subclass
of CPane.  Then your DrawElem should be declared
        DrawElem (CPane *obj)
        ...obj->Draw();

You can ensure safety by creating a specialization of CList that only accepts
CPanes as elements, and using that as your list-of-elements class.

This fails if there are components that have no visible aspect (a weird,
anti-WYSIWYG notion!), i.e. that don't derive from CPane.  Even there, you can
fix things up in your DrawElem routine:

        DrawElem (CObject *obj)
        {
            if (member (obj, CPane)) {      /* if it's drawable...  */
                ((CPane*)obj)->Draw();      /* ...draw it           */
            }
        }

Hope that helps!

=Ned Horvath=
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Martin Minow 13-Mar-1991 1438)
Subject: re: recursive drawing
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 21
Date: 13 Mar 91 19:43:17 GMT

[e-mail] (Bassel Soudan) writes:
>        In my CComponent::Draw() method I call
>        DoForEach->itsElements(DrawElem);
>        In DrawElem (CObject *obj)      I try to do the following :
>        obj->Draw();                    All the elements that make up the
                                        components have a Draw message
                                        defined.

I would approach this problem by something like the following:
1. create a CDirector sub-class which "owns" both the data and its
   visual representation.
2. create instance variables with the data
3. create instance variables with CPane (subclasses) to draw the data in.

Now, as long as the CPane's are enclosed by a CPane that is drawn, they
will be drawn automatically.  Each CPane Draw() method would understand
how to draw its data element.  Take a look at CClipboard for one such
example.  Note that the TCL does the DoForEach (itsSubviews) for you.

Martin
[e-mail] (new address, please update the mail database)










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: TCL app's stop Moire cdev
Message-ID: <[e-mail]>
In-Reply-To: Mark Alldritt's message of 13 Mar 91 04:42:41 GMT <910312856*[e-mail]>
Newsgroups: fa.think-c
Lines: 22
Date: 13 Mar 91 20:26:53 GMT

Moire, SuperClock, AfterDark, and many other programs work by
"leeching" idle events off of the frontmost application.  Since the
TCL is extremely MuiltFinder polite, it uses a sleep time of MAXLONG.

To change the behaviour of the TCL, you should override the
CApplication::Idle() to something like this:

void CMyApp::Idle(EventRecord        *macEvent)
{
    inherited::Idle(macEvent);

    gSleepTime = Min(gSleepTime, MAX_WAIT_TIME);
}

where MAX_WAIT_TIME is set to whatever value seems to work best.  Try
using 200 or so, and work from there.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: A problem, and debugger limitations
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-Vms-To: IN::"[e-mail]"
Lines: 78
Date: 20 Mar 91 16:12:41 GMT
X-Envelope-To: [e-mail]


I have some problems with a program, and I think it is the following
function that causes the problems.

The function should remove all resources of type theType from oldResFile,
and replace them with all the resources of the theType from newResFile, which
is read only.

My problem is that it often works, and sometimes I get multiple identical
resources with the same ID created in the same file, even though there is
only one copy in newResFile.

I tried to add a breakpoint at BKPT, and it shows that it is adding just
the resources as it should, so I suspect that the error is caused by some
some handle/memory being moved around. If there is anybody who can help
help me, then I would be glad. It really irritates me that it sometimes
works.

BTW: Is there any good method to debug THINK C projects that do a lot of
work on their own and other resource files ? I really hate the way it works
now. The program being debugged is type PROJ creator KAHL and not APPL/SIGN.
And I spoiled my resource file the first time, and I have to copy a clean
copy each time I want to try running it for debugging again. I am also not
sure if Get1IndResource works correctly. Does it search the resource file or
the project file ? I guess we need a standalone debugger to open anapplication
and the source code. This would surely be better here.

thanks,

Povl H. Pedersen
[e-mail]

--- code follows ---

MyMoveResources( theType, oldResFile, newResFile )
ResType theType;
int    oldResFile, newResFile;
{
    register int            i, NumTypes;
    Handle            resTmp;
    ResType            myType;
    int                Itype;
    Str255            myStr;

    /* Remove all old ICON from file */ /* This Works */
    UseResFile( oldResFile );
    NumTypes = Count1Resources( theType );

    for (i=1; i<=NumTypes; i++)
    {
        resTmp = Get1IndResource(theType, i);
        RmveResource( resTmp );
        DisposHandle( resTmp );
    }

        /* The next part does NOT ALWAYS work, it sometimes creates too
           many identical copies of one resource. */

    UseResFile( newResFile ); /* read from new */
    NumTypes = Count1Resources( theType );

    for (i=1; i<=NumTypes; i++)
    {
        UseResFile( newResFile ); /* read from new */
        resTmp =  Get1IndResource(theType, i);
        HLock( resTmp );
        GetResInfo( resTmp, &Itype, &myType, myStr );
         DetachResource( resTmp ); /* do not use */
        UseResFile( oldResFile ); /* write to old */
BKPT
        AddResource( resTmp, myType, Itype, myStr );
        UpdateResFile( oldResFile );
        HUnlock( resTmp );
        ReleaseResource( resTmp );/*delete in map and free*/

    }

}










Path: ucivax!gateway
From: [e-mail] (Rich Siegel)
Subject: Re:  A problem, and debugger limitations
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 21 Mar 91 00:30:53 GMT


When your program runs, the .Rsrc file is at the top of the map
chain, and is CurResFile(), so all of the Get1xxxResource calls will
behave correctly with your program, unless you're trying to muck with
your own application's code resources.

R.










Path: ucivax!gateway
From: bootsie![e-mail] ("Eric K. Olson")
Subject: Re: A problem, and debugger limitations
Message-ID: <[e-mail]>
In-Reply-To: vax.ftp.com![e-mail]'s message of Wed 20-Mar-91  4:12pm.
X-Mailer: Mail User's Shell (6.4 2/14/89)
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 110
Date: 21 Mar 91 00:41:24 GMT

In a message of Mar 20,  4:12pm, it is written:
> [...]
> The function should remove all resources of type theType from oldResFile,
> and replace them with all the resources of the theType from newResFile, which
> is read only.
>
> My problem is that it often works, and sometimes I get multiple identical
> resources with the same ID created in the same file, even though there is
> only one copy in newResFile.
>
> BTW: Is there any good method to debug THINK C projects that do a lot of
> work on their own and other resource files ? I really hate the way it works
> now. The program being debugged is type PROJ creator KAHL and not APPL/SIGN.

The project file is of this type.  You shouldn't be manipulating
resources in the project file, however.  You should modify resources in
your project's .rsrc file (this file can be of any type or creator,
usually a ResEdit document).  This file is CurResFile() when starting up
under the editor.  The application will be CurResFile() when starting
up, after being built.  Just save this refNum in a global and you will
always have the application's (or the .rsrc file's) resource file refNum.

> And I spoiled my resource file the first time, and I have to copy a clean
> copy each time I want to try running it for debugging again.

This can still happen.  Having multiple resources with idential types and
IDs is a serious offender when it comes to spoiling resource files.

> I am also not
> sure if Get1IndResource works correctly. Does it search the resource file or
> the project file ?

It searches only the _current_ CurResFile.  I like to save and restore
the CurResFile around Resource Manager Calls.

The Macintosh Print Manager sometimes sets the CurResFile to the most
recently opened file, on exit from its routines (this is often correct,
but not always).  This can really cause trouble if you assume that
UseResFile(appRefNum) is permanent, and you have another (more recently
opened) resource file.

I suspect you are getting double resources because the remove is
failing, not the add.  Check its return code with ResError().  This can
be caused by the resProtected bit being set, or if the HomeResFile() of
the resource is not the CurResFile().

It _might_ also occur if the resource is currently loaded into memory
and HNoPurged().  I can't remember if I found a bug in Get1Resource()
that returns any already loaded resource with the same type and ID (from
any file) instead of the resource in the CurResFile().  Perhaps you can
check this out.  If that bug does exist, the RmveResource() would fail
because the resource's HomeResFile() would be the CurResFile.

It's not very easy dealing with multiple resource files.

> MyMoveResources( theType, oldResFile, newResFile )
> ResType theType;
> int    oldResFile, newResFile;
> {
>     register int            i, NumTypes;
>     Handle            resTmp;
>     ResType            myType;
>     int                Itype;
>     Str255            myStr;
>
>     /* Remove all old ICON from file */ /* This Works */
>     UseResFile( oldResFile );
>     NumTypes = Count1Resources( theType );
>
>     for (i=1; i<=NumTypes; i++)
>     {
>         resTmp = Get1IndResource(theType, i);
>         RmveResource( resTmp );

I think the above call fails when the resource's "double up".

>         DisposHandle( resTmp );
>     }
>
>         /* The next part does NOT ALWAYS work, it sometimes creates too
>            many identical copies of one resource. */
>
>     UseResFile( newResFile ); /* read from new */
>     NumTypes = Count1Resources( theType );
>
>     for (i=1; i<=NumTypes; i++)
>     {
>         UseResFile( newResFile ); /* read from new */
>         resTmp =  Get1IndResource(theType, i);
>         HLock( resTmp );
>         GetResInfo( resTmp, &Itype, &myType, myStr );
>          DetachResource( resTmp ); /* do not use */
>         UseResFile( oldResFile ); /* write to old */
> BKPT
>         AddResource( resTmp, myType, Itype, myStr );
>         UpdateResFile( oldResFile );
>         HUnlock( resTmp );
>         ReleaseResource( resTmp );/*delete in map and free*/
>
>     }
>
> }
>


--
Eric K. Olson, Editor, Prepare()      NOTE:     [e-mail] doesn't work
Lexington Software Design             Internet: [e-mail]
72A Lowell St., Lexington, MA  02173  Uucp:     harvard!endor!olson
[phone]                        Bitnet:   OLSON@HARVARD










Path: ucivax!gateway
From: [e-mail]
Subject: _SwapMMUMode doesn't work
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 28
Date: 21 Mar 91 02:55:22 GMT


Help!  When I step through the following code:

    short        mode, mode2;

    mode = true32b;
    mode2 = GetMMUMode();
    SwapMMUMode( &mode );
    mode2 = GetMMUMode();

mode2 == 0 before the call to SwapMMUMode (and mode == 1); after the call,
mode is still == 1, and after the 2nd call to GetMMUMode, mode2 is still == 0.

What is going on here?

(I have the Profiler, 68020, and MacHeaders options set, and the MF Attrs ==
0080 : 32-bit compatible).

Thanks,

Mike.
_____________________________________________________________________________
Michael A. Kelly                                   America Online: Michael792
[e-mail]                                  Compu$erve: 73567,1651
_____________________________________________________________________________
"I know not with what weapons World War III will be fought, but World War
 IV will be fought with sticks and stones."
        - Albert Einstein










Newsgroups: fa.think-c
Path: ucivax!jhummel
From: [e-mail] (Joseph Edward Hummel)
Subject: Help with malloc -- fails for large n?
Message-ID: <[e-mail]>
Sender: [e-mail] (Joseph Edward Hummel)
Organization: UC Irvine Department of ICS
Distribution: usa
Date: Thu, 21 Mar 1991 10:50:11 GMT
Lines: 17

Maybe someone out there can explain the following.  I'm running Think C
version 4.0.2, and if I do the following, it works:

         p = malloc(16000 * sizeof(int));

But if I change the 16000 to 17000, it fails -- p is set to NULL after
the call.  17000 * sizeof(int) isn't that big, what's the deal?  Does malloc
behave strangely under certain circumstances?  My program is one big main,
could that be it?

Thanks in advance.

  - joe
--
Joe Hummel
ICS Graduate Student, UC Irvine
Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: Re: Help with malloc -- fails for large n?
Message-ID: <[e-mail]>
In-reply-to: Your message of "Thu, 21 Mar 91 10:50:11 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 31
Date: 21 Mar 91 16:05:17 GMT


> Maybe someone out there can explain the following.  I'm running Think C
> version 4.0.2, and if I do the following, it works:
>
>          p = malloc(16000 * sizeof(int));
>
> But if I change the 16000 to 17000, it fails -- p is set to NULL after
> the call.  17000 * sizeof(int) isn't that big, what's the deal?  Does malloc
> behave strangely under certain circumstances?  My program is one big main,
> could that be it?

One oddity in the ThinkC compiler is that sizeof() is an int, not a size_t.
(User's manual, 7.4.8)

So you are getting integer arithmetic for your computation...which overflows
to a negative number (16000 * 2 == 32000, 17000 * 2 == 34000, which is greater
than 32767, and therefore won't fit in an int).

Try 17000L * sizeof(int), that should work.

By the way, how do other folks solve the "sizeof isn't a size_t" oddity?
I've been casting the result to size_t in code that I've been porting, but...
I was hoping for a better way.

Regards,
Dak
--
David A. 'Dak' Keldsen of SoftQuad, Inc. email: [e-mail]  phone: [phone]
"...Then anyone who leaves behind him a written manual, and likewise
anyone who receives it, in the belief that such writing will be clear
and certain, must be exceedingly simple-minded..."   -- Plato, _Phaedrus_










Path: ucivax!gateway
From: [e-mail] (Brain in Neutral)
Subject: Re: A problem, and debugger limitations
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 5
Date: 21 Mar 91 16:05:29 GMT

One of the problems with removing resources is that it's best to remove
them in a loop that counts DOWN, not up.

Paul DuBois
[e-mail]










Path: ucivax!gateway
From: srauseo@128.38.16.7
Subject: Getting a PixMap
Message-ID: <34.srauseo@128.38.16.7>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 42
Date: 21 Mar 91 16:32:30 GMT

  I have two video cards, one of them a RasterOps ColorBoard 364, which in
addition to being a 24-bit color card, also will grab a video frame to the card.
I want to be able to get to the PixMap of that screen, but I am having a bit of
trouble.

  So far, I have been able to select the correct card and get the handle to the
GDevice, and thus the handle to the PixMap associated with that device.
Here is where my troubles begin.

First, I have the Inside Macintosh series, but not the documentation for 32-bit
Quickdraw.  The Inside Mac does not describe any more than one pixelType for a
PixMap (that is Chunky, pixelType=1).  The pixelType on this device is 16.  What
does that correspond to?

Second, I have a question concerning 32-bit addresses.  The baseAddress of the
PixMap for the 364 board is shown by the THINK-C debugger to be 0x000000, even
though as a long int it is 0xFA000000.  (The same for the main screen--the address
is listed as 0x000000, but coerced to be a long, it shows up as 0xF9000000.)  I
assume that this is just a sign that THINK-C is using 24 bit addressing.  I am also
then assuming that 32-bit Qucikdraw will be smart enough to use 32-bit
addressing when I do a CopyBits.

My last questions concerns the color version of CopyBits.  Do the PixMaps used
in CopyBits have to be the portPixMap of some cGrafPort?  I would like to be able to
copy from the PixMap associated with the screen to some PixMap created in main
memory without having to create any intermediate CGrafPort's, but I don't see how
CopyBits will know it is a PixMapHandle and not a BitMap without the high bits set in
the portVersion variable.

What I would really like to do is get around all of this foolishness and
directly access the bytes in the PixMap data on the card, but the 32-bit addressing
seems to be getting in the way.  Any hints or ideas?

I am using THINK-C 4.0.1

****************************************************
*                  Steven Rauseo (R44)             *
*         [e-mail] [26.1.0.102]    *
*              Naval Surface Warfare Center        *
*              Nonliear Dynamics Group             *
*               Phone [phone]               *
****************************************************










Path: ucivax!gateway
From: [e-mail] ("Bruce Florman (BFLM")
Subject: Re: Help with malloc -- fails for large n?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "[e-mail]" at Mar 21, 91 4:05 pm
X-Mailer: ELM [version 2.3 PL3]
Newsgroups: fa.think-c
Lines: 11
Date: 21 Mar 91 20:05:21 GMT

> By the way, how do other folks solve the "sizeof isn't a size_t" oddity?
> I've been casting the result to size_t in code that I've been porting, but...
> I was hoping for a better way.

How does everyone feel about this:

#define SIZEOF(T) ((size_t)sizeof(T))

It's a bit ugly, but it is portable.

--Bruce Florman










Path: ucivax!gateway
From: [e-mail] ("Bruce Florman (BFLM")
Subject: Re: Help with malloc -- fails for large n?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "Joseph Edward Hummel" at Mar 21, 91 10:50 am
X-Mailer: ELM [version 2.3 PL3]
Newsgroups: fa.think-c
Lines: 27
Date: 21 Mar 91 20:10:42 GMT

>
> Maybe someone out there can explain the following.  I'm running Think C
> version 4.0.2, and if I do the following, it works:
>
>          p = malloc(16000 * sizeof(int));
>
> But if I change the 16000 to 17000, it fails -- p is set to NULL after
> the call.  17000 * sizeof(int) isn't that big, what's the deal?  Does malloc
> behave strangely under certain circumstances?  My program is one big main,
> could that be it?

Try changing it to 17000L * sizeof(int) and I'll bet it will work.  Since
THINK C's sizeof operator returns an int rather than a size_t (this is a
mis-feature IMHO) and since 17000 is in the range of int for THINK C, the
compiler evaluates this as an int expression.  However, 17000 * sizeof(int)
is 34000 (0x84d0) in THINK C, which is beyond the range of int (the high
bit is set, so the quantity looks negative).  I assume that you've included
stdlib.h, so the compiler knows that malloc takes a 4 byte argument (size_t),
so it sign extends 0x84d0 to 0xffff84d0, which as an unsigned quantity is a
little over 4 gigabytes.  Since malloc can't allocate that much memory on any
current Macs, it returns NULL.

By changing the expression to 17000L * sizeof(int), or alternatively
17000 * (size_t)sizeof(int), you will cause the compiler to recognize that
the expression result requires 4 bytes.

--Bruce Florman










Newsgroups: fa.think-c
Path: ucivax!jhummel
From: [e-mail] (Joseph Edward Hummel)
Subject: Help with malloc...
Message-ID: <[e-mail]>
Sender: [e-mail] (Joseph Edward Hummel)
Organization: UC Irvine Department of ICS
Distribution: usa
Date: Thu, 21 Mar 1991 20:21:08 GMT
Lines: 29

Wow, thanks for all the responses to my plea for help with malloc.  The
problem was this:

        p = malloc(16000 * sizeof(int));

worked, but

        p = malloc(17000 * sizeof(int));

didn't.  The problem turns out to be that since ints are 2 bytes in Think C,
the 17000 x 2 becomes negative (since 34000 sets the sign bit in a 2-byte int),
and then this value is cast into a negative long which is then passed to
malloc.  Malloc then promptly chokes.

The solution is to cast either of the two operands into a long: e.g.

        p = malloc(17000L * sizeof(int));

I think what I'll do is create a sizeof macro for use with malloc that
casts its result into a long (or more correctly, to a value of type
size_t).

Thanks to all who replied!

  - joe
--
Joe Hummel
ICS Graduate Student, UC Irvine
Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: Re: Help with malloc -- fails for large n?
Message-ID: <[e-mail]>
In-Reply-To: Your message of "Thu, 21 Mar 91 10:50:11 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 17
Date: 21 Mar 91 20:27:12 GMT


   From: Joseph Edward Hummel <[e-mail]>
   Date: Thu, 21 Mar 1991 10:50:11 GMT

   Maybe someone out there can explain the following.  I'm running Think
   C version 4.0.2, and if I do the following, it works:

         p = malloc(16000 * sizeof(int));

   But if I change the 16000 to 17000, it fails -- p is set to NULL after
   the call.  17000 * sizeof(int) isn't that big, what's the deal?

The deal is that 17000*sizeof(int) isn't representable as an int, so
it gets truncated.  Try (size_t)17000*sizeof(int).  Since size_t is
long in Think C, you'll get better results.  The brain damage here is
that typeof(sizeof()) should be size_t, not int.











Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: THINK C header & lib for HyperCard 2.0 XCMDs
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 252
Date: 21 Mar 91 21:29:09 GMT

Here's the official conversion of the HyperCard 2.0 header file and
library for THINK C.  We've tested it for a while and haven't found
any problems.  This release fixes some problems that are present in
the copy presently in your archives, so you will probably want to
replace your copy with this one.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]

---------------- think-c-hc-20.cpt.hqx ----------------
(This file must be converted with BinHex 4.0)

:'94)58j,)%-J5%-b,M!J5'9KC'9bFbjMF(3!8%&$9%033e3"!*!$,#i!N!6Nr`%
"3TJ!!#ZeD3!!UUUQ!!B!N!P!Q3!!Q'"SHAH*Q)U*"jQD"hCfH'F+KhPkKfLAHTJ
+#!4P9'CPYeC8D999GhHD#`!+N!!!N#B*)!!#-d499PCfPhGQGRGhKjL*KjQ(Q)U
B!+N+N!#U#TS*U8!M49@3!fCfChGfD'GiQ*GiL(L)Q)QCLSL+#3S*#3#UUSS!N!#
!UU!!UU#C#DQBN!#UQR#3!*UDN!#S#T!!#3QJS!#U#U$kmRr[hqr($)!2&SmpmVH
l0ZTi0T!!Ic5ee@9Ae6XKVUVP$A1f"NHD0Y-1l0dmed)f!+jmh9G#Ub'EJ3LB3c6
hqGY@cEI$kU24$LqllZ+(CjlSfAbS!jE[RE%Na`3Kb9e`-UZKE+k9[K+P9$DGS%J
QEj@kid5#ZYP$9'k9-!bQk)'+Se`S89XU60pAR$Nhl`f1DHlIJ#A,$SXSi-SBMfr
hp)BhK04BbGepH2(MqQVAC6,A#(cqHMrIARq"1DqIcar5"5Ub6B,3Ka,Q26'M5(T
A!ZUXSV`TP$le"6JfrMMqQ9P0@YBbqHI`PCIdl,9c&38D'26+c"NB*%fKITPjAjk
DVec"38D'2CI6cL6[Ahl&c0B@D'[E9C62aC-ZU+VQIej#N[KAH)c8L3@6kmBElG$
rZ2b!afB883r#($P-1jie9S#ZUGr4Zhj4&`)!SFmYFk1m)1bkm8&Z1SZ42hi2(E'
rJi1!NcMm[bhbXcq&i5I&`j!$PaBX33&qd9Ge@hAS-S4eLDF21H"d2SYN+%8NJ2,
0A1k3!%"PaIqrIqB1J5@`m6F[#Uk'U99Q`Ph3$#JLb(eIk`U[rak$2[G9i5q1mS8
T3ImN)-e1#iMdiMSDj*Kf6`XT-a0V@4J6HA%43SfaXXP@SHk+UCGFDjAhbZ@2VTl
T6&@G%Dk`dK%ZM-S6QFGQfILq4`4+b1#ERiKj*3E%(%R"#hmI`B`S5jX$KraF2UB
NK#kT',F&)4T(J*+MrA'kq6B3'*V)#Z8E@5")63k%8j6-2e+Y4G4E9[[KYMG#iTK
R#D'k9edGJN,H-8+*#GNVqZfHpK)'k3RNT-AH"b9Yk'XpcD@E()XcB@h6YlDVpS[
R$0rBE0JcS-C+MhLJG+@58%4b@1a,MrY9FIJ,k%Z0VP39AdE)9Abh&J+G@Zi'k%"
baYc9e8GmQ&*5Gf#!,@1UBLcI-9Z3!,K,DcdqR$I5-5-+YF,*5T4LD&MC68lBhdE
HLcA0,*H[KiXT*!V6[#)`-e$De,3NT"Va)aPDQRCa&cffcY@B[I@-l*ZeUX$PMfl
GmaRc-cjTDX0LaNL%aZqS3j5(d'4r4#*3kS'I#Z,%pl,j,aLfe9Kp"V#XXlLT4TY
$%,bhMZ$La#))#'SRb!K+e*8bjafh,YUm&ddQ&3+MpYk,!a1FVTr9`rEl8PChf98
R,@'bd5Ye6mL0!CG8rF"&8dpC@%NRKGe5@RP3m'"3T*3Nfr5FpbaTl'DSrB%CaI0
BV'k&LCcl%e,Z"aC08l&2L1`Dqh+3!'k4NkdLPK)E,M[RXf9bd)KD*dirrq-D2Nk
80dI,0%6ATcEC8Gp`DRLpKV8$0@iD("SJe#8FpBZe"%Fcchi)U3M1$T6qME(GQ&m
&j9QPE@+ba*dB0,D,2(E)Z!%Y!*A3&)@lI+JYlVZdLc2BG6kM2#c)k[$VXPEdFf,
&q%26kZ0BKr00G6B4IB`)Nee$-e-amL$l@"!G!0KRBTF"heKljEP3J0hrPUrq'06
V[Yp2ic-,rb)Q#aq["Mfr`jfJL`S2jFHV[f@8J1bik"1-`RA9+Y!8+[ljf!,1)pi
eZ&ZLhAfi8AM5pZT4THb%&KFFF!R@3jrh(L'4qfpK$,MaBS"Y1M@'#p2%80V"Nbm
5YI2)Mh*S)EDiY!S!-MTRphbi[CrcM9&,CAi@fIQ6S3+mXjM1B-JXEVZHZ1`0PL$
+LaDqhckbQ@&bDk%UbNJ14%0#!eE[0NX80IE,p3rHm*K33,@B!qZBQ29Cb@l,[Pl
5Bda%AQQ*ID"*QqcY2Z9PH%(h,"VBr9J5KqjK[`P4--`HX!+a($8EPL%N"kM#'*p
D(dIF`I1Bam%Z!CXkY2d-kaS9aUXi`*&C*V8Q%'NCDD1r,!k*j4#1d!ad0b`%Pd8
01%CYHCGeBELLXI(EVPE+`Ce&XBbH!8F1k#jBp05G(-SlXPBX()95`JE#%(Nlem(
I(P-kaMZb*#MGZS5V#LT!L#bdGe8#UpJm[YhbCCVdcD&YiYlJLQT3@KmEbZ[U&XX
#'aE6j$Zd(@5+Ti*N0R'-R2jElIU6CDM%N!!*b`l,l4Q01D`)I4aXN!!q"B)&`2&
A'R0+kSEGGXFd,Sc2dJrKKBKb,0a+A9M[BN3K!U2YkCETfqEZqSF6rZVRUM@kY&X
"(e$9BiZUIC!!LVG%)RQ3!(",IT+fI,jMPDEdX3G6F9+XSja"9X3+Gq$"j#&fmRN
)F&4'c62i(I'e9q3&eJ#@V`c3*0QrNr8`+3efIpF(M!F@%m6)3p6DP6HSJNpmV0P
qeUb`2@E+%0S2ZNY2cUb'q)iZlE%*#q0SjRR15'Q9Zj%[R5Y%!hSiaUcrXq%LXdl
2!GqFGlei5-+#1QB-fp4U3Ye!)C3&F'ecq9lLM+Ci&c%j"J%qL,piLSiS`iiEjh$
2%qL-"4TRSPj1+,0P%E8&R09XU[ZHbAG'LGR9TN+2%@jBMhCL6eK1,&Q1`hhYU+%
p2k00SFDHA&'N13b@d2XMLb6DCKdE@aEpJlJ)eXa6A!0H'2h6-JerElc2a9@rqUC
6*VTQ99ElX8XILJlrR%(*pj)"5Bf6H-YcM'SdH8SAQMPCMZD11i"rNYP,LHFZ*el
DQM,qAck1CdZ,,M1-S,R(8akTiaA'ejC0PU4HbG@FdDKDEb6FSfNcRQhi1(,I[IY
l20P9jm$%4V'H5VHlkFH*[I8VZ3[9C[brPfG"TcXSeDFlm`0C,jR1NpqJ@1BhJl9
qf%GQ%bV1j-AdjcCE%Ybr9A85VVMC+H&cEEA![R6j2IliG@IY2TREpB%YP9RFIAL
fZ0DlmYP,kQ#Mc$MU0R8@R'fZlZZ5+HThMKZa&l0J5Fj"2[U(9JAK!)*%"9&"'l[
q)r%(,$mZ`LH'3N53!&-8lKA@jp#`D2Z(d%Pp-6HdD'2b&kd!QPa"[cESeZc[Ueq
E["0(cHRdV0kpAkEXKr9NjSC2lB1AK(@qZBZY!a0I(qMVPBj!'IK[@3h2E1brQR3
J5HEVdkGbkA`TAcdqT+fe&)L'MeVFJm5E0r5#5Q[B,-epbQdHK5pXh,-aI[QA0ZA
P8jUVKhhb$P[ZaI1a*Cl(9,a3GYce&0Air5DbQiJaGR,kVbT$MK"A&pi9A9$K@8F
HARJ*b#Z@QGFf'AMAA-h%ZNG4ABm@JZ1`FE24qIGkE#N,iQC8'(iBBkUMrP4cB"X
UPRiX)cU43ILkYXl1ReYEBpQlZDr!E5Sf5fphDAYVGR4C4ial-&,-J&V3+Y5M(+"
Sl4hGfp!1G066GeEPBRbd"&$lHA"+phESL,c3-@iEalhDASQP'efam*%DZ+Gj+r'
2RGdcm"X3f-p#MQQpb69c6GFr(i5cMd0aXSEX!RJR"k1Tq2CjPr3Sfp')X@$ppc#
SS[q"2i8XqVCkkHHdN!"26%'ee&[p34$HM0fME@j4GjhPlU(HYrV&4YkQYP[ADZ[
6ETcVh1EC4TBrKiMf+(!BGBef'rH@@0mi"XIba+j&!LIZ@HZR9e0FV*5(jq[H2E@
8a@p(mmlGdEd15FrX[4r&QJ"LE4mL[aM0L&UEIVJ2LDK+YA!#b6ZlAXXA,Ji4q[M
AScE0QUGM#mP3*1[%XJmFQRDU",I$b%2LhiN+r5KBU"5TG([,,'aT%64m"(m9-Qb
h*U"HeC*UqQEh,brd*bGNT3)[mR'F1EA8)AT!6kX'GIbHr'ReBUHQj`P)P$Z[,kP
%X["DS,(hFXCHBG6c!,4YAk%XRK&iXB2l+HV%)%JNf6,%*+XPr9EZ&C+VNE1f4DH
aK@LJ%A@V%0%CLrTShLSPVccq520E(aE[[NF'BdfaSNq9%aT8SNQLJrrdI,M9Va$
N5'*,iPbi(fG%IPLC!!#!9@GQH(KRH'GiHBQ*HTPkL&TjLATjQSQ)H'GSLBQDHUP
hCfH(D)PiChPiHCKkJ)#CKjH'CiGSH(GiGhDCLCQDQBLCQTQDV*bCLjZJV*bJUmb
+ZCUVL*!!S,#3!*!#V+#+J+#JLCbFN!#CQTZDJ*U)S)UJN!#kS+#3!*U3!,#FQS#
DLk#-M(U()!!#*%494@GhD+@(L*HSHELCUUZl#`!!#F!-!,!,#m`)3#0%9PCQCRG
RKhKiKiKfGhQ(GiU*LSQTQCLSU*LCLDUCN!1*Q)Q,QjQBUCQ+QTZDQCUCQCbUR*Q
EUUQUUDUjQUU##%!Q,kF%'m!*$6!EqhFBH&Z!%IbR6Hk[J%I0LEMl'h!4dlbKY,k
YRq$Q8Fh%[mM[YGqH-"A"`X$EGaGclq'$LH2(ZL#[35XI5r9h9F!LVaT8ciS+1ai
d%'MS`361L!cm#JcT!-ik3ck[`!-p--Z$qKpi"RL*'-,lJ$24JM)$23!Cpe3B56L
U$2[J-md"9@!cMJ-mQ4`0rLll*KPiZE[iZ"Lj'9""Tma#Dl[4JepG&P39PjmfM"Q
G[DFrZIEdG#fbS+kl!Kf-q$"lAa))d&rVpE"2LlfKaHcbB-b#`YZpSGj&hZ$J81B
rZJ)9S"qMU3pMU!(4+Za"mJSYAr&&B[jGbZGN"B-)"$!BB3h91@!rhd)+jTUV!&9
FdB9Ej-&ZeC[m`#qQpLMU0Z%Q#A8Gh5Z`-!),5GDY*I4bB-k$82PUUTp5&*Je(GN
-r#fLIH%%U`ed&G2iFrPpMG0+5`ENqN[L0fQI-EV%&8U$"YbV#UX0"eL!kVfcU8q
&9+IC92jT+dMc%"KBAIc#(ML6$kM`XZNc(,T@R2Y1HU0h5G$l@[e6aecrV`9VY3J
rmZ$D9pCSdPp8`*J&fEjJ%rK"DjqT0+aq,GJX55@,%JT%V%dL!ke,rf'6TCb8hK4
QSGNCBZpRTql'G@rUPi(dTSqFe(I3IU6ba#3X(,Q-SlV(iY12PMV*q,DcKI"!5NS
"P&BL%9Z`LYHl3Fe,Zb'T#3e$53X@8KB-T#ZJhD%Y[!PVGYS,&hca0BqqH*@!Ll"
e)YGrjS9"IFk#*0V*f[Z@)[ZG!fmP@pV0L`%'Ue+@d&qES!5a'S4&Z+k$H)C6HKC
GLYCEE*JSERPcS2Sh8%@C'p8"f2(QJ'CGDbDDkb##e#,(eJL0PFe*4E0`5e$Xp@a
HVe2YBXCP-F@+YNY"I@bB-ecBUd8`f+-F3QVTq9Sp#IN`B1CBDq#Kq5#!)UdIrk5
QS4!4PQPD64SkbQi%@$Y!MXRDK5ZIQ"eF$DC"IX5h2hYA+Qie$&pS"PJ'mk6#--c
a()[h4IZ-U6LfSe8TKjN"Tf3$EYQ*@m91j[3%'ZcI!bV&'@5'LhVXl&Qkc&D1K2r
R"C+UqC@epmd%VXGa"L-UEG[P,DQrrKC30fK&fG+,mfG-Ykd&1Z6)!dQ$$DB`b[E
jqXQP*mjT"Bc-I$'5N!$$',6$$&,F&mkNMf0XGrMLY04FF[p`(q13!0CN+PPN2kj
%#*j(m&aK9elpl($hL"p*r-30qr+@A1eN[ZdMc0eUhc0dY58hh8MPiYJr@A+@r4K
F2pFXlp6lYaU4DJe$1[BrE4!pjmi8V-)$V@F8&NcTBDK#%X(TA*rXfN(&CPJcTE2
A)"llqCZ2GI&A")2EI""*DQH-22FFV$GZDI2e[c4-j5R-Hb8dIR9A"rBk%%[RM48
rYD##(AM4B1KGp*%[4#Xc6l#kJ[b&GR[S*j10(jk(&++`2k'"elLBH(J$H*0jTNk
B3PFT#9cSK!8D1Ji3J2m2!#*JJMHf!6RRH%MFNEfX8&Rfpc"$b1K(NU#08S)PU#+
#JMb9"(TU#2D8%I'N)dLMJ*VKN!"'!J!P12XJUY!"@NK'k6""d9KIbV#rL@&r#X,
jU`[hPKIXV#rd,#rbV#rb,#r6@&rJ@&rG@&qDX,mPBAiL`[2@&j+`[HV#pfX,`eK
GqX,R,#lPN!#i9ZM#YdB9ZM#YdB9ZM#YdB9ZM#YdB9ZM#YdB9ZM#YdB9ZM#YdB9Z
M#YdB9ZM#H!j3AXeKGZX,YPKF5`Zb@&f$)A'ib`[d9KI&@&qBX,-k+J[K,#c`%U#
pmX,hL`[%@&i+`ZHX,@k-CESaPZM'@k-CESaPZM'DG'X@&J+V%[MdP[iE%bJ[j&K
Im@3ZU@k&9[1laFhDj9)GiSKfl2IPd4hGN!!F84@Q9La%Q"Sq6(UY-UY@KGhkV!0
H,ABLqD+cBc6*T*%!5N`J%,+a4)p*4*IeaREY8555N821,58X85TRRe)RAJK-K&U
KiDhlU*hda5P)Jr+4,Y9SN!$*08BU9D)beBI&0,&@L'-N6P',bB2b40ZQDA9#R&0
*2dbXZY%TN!"9)ShVKXa`3@fMe&-(e8N!YGT*S&5&GE9C-hK5GYrPlp$P3BB"+@Y
ZGV3RBP$P5-UqkHMlYVjS"[EYI*)e3j8EMd199fS$2K!*ajZ22i@MScmZ#22h*c@
,6YY(eU(+U[(SIqV##,J3C0$LmMSpcdT2HH,!$VTipCYZ,MakcQ39G#T&Xj2#T9f
YZGeJ8,d+U2&A"68VAKd+Rf22epc1Zm1lQir)id@jL`E6KD@XLdh&qf##KDm2MDl
NHPVENq2#KbSr[J8f9VjZYZCf&Hhi%2daAm8I(VU(+Kr0(iBGkZTG'Kdj&-D#All
[TD@`Y-$-LifZc)HCTpeTrJjGhdi,(-NFEAGejiF#0b2qe$[+&6ACZGQid&pdj(c
@[*Nq*VpR*iG+0LHI3U6rjk25q[Vi,NZC[*)D+Xj(iSYAaVS1YV-HGIG2UFQemb+
`arMY,VEIi8KcUS1AVEQm5bQYapB6TKQS1%bcA+Mm`09q#rrKUp'K8c+rNHi)%H)
!3594qL)4F+6m['l!3!RfPP[*0hmN&CR`q6CFcf1jpc4k2&mcQIET4U&5dJifZ*4
&$aYCDB1"r64jF@"0im&MX-JF,fTih9cIp*q4"A4B()qHAC!!9RrM@BR1pHCC@PP
P5mI8i9hMeB"1YS9*GYSKMSH6qc#C$2-D$21rCkQMe"a'Z9$3PpM"AEE)JNdV2$Q
dkl-aZ4lQ&0TG)PJ(X2i14"+8'C*$!14b)ARr0K'r6h0,Qef,fpc5pm#eA*T`GCS
p5Ap,%Zl6`[lq*m(q(SEC#`,55VhrQ`Jjh2Q@@2,$8Dc(PB9h5e#Q+e1mXNK8(bE
b8S+k'mU`0@(`IpIfHJ))&")@NAKIhX)Zfr[BEBHQ6(YTGY"EBpTV,D#bqa0[2rX
&Kqcj))r1qa,d1hZC[d,(j)2V5p$NG$ZEZPmSNQZN4JZUAY&#D([4GYSHpQk1I!K
%@AkED$ke+af44eGcEceZ2"(Sal5fJMY((l3EHT&JalXF96erMfe[l#D8Vc!RA[E
k38TGlJLF5+XS9,E`Y$[l62XS2mIPJfIl2H3)Gjl'K"G@NbbXJ'8[JqkJ8fbK5Xp
$PD&"!PXe#9Km(+d0QJ5Y9#8HViJB5`-3Y(r0Q0JK"SmRH4`$IY-9Jl(Hbl+CCHV
LERh0(TlDEMp5Kd)Y"3Tk,3Tde#Nh+Nm@li&Ac,Ulk![9@"("TSkq#2VlZ#2DDq#
XerHM-!rRFMVZfX-qEl2rZfJl+'IHqhrmjXkI0QcHAkr-mHrrK"FfQV#kHKYX"Q0
3#`*"jVi)2%LKI*&VAb39bd&YZ(6XpYa+GG1iFlL!DL!08RF-"@T3*9!158$9@"D
TVVNrp-pEKieAD$M6d+RUqAheG`rARh8Z#EG6lUK8pEbqqkhA)$#,6llkm%qqmle
lI56lkAT+&3`5rPjRm[YJQkA$pIPqA,U[BjHZUTpplr,Rhh`HA4V23mI[Sj@QiZY
jmAL`'fm*V+Y%e'Vai)2pE@k!K@mMm9VUiUffUX+qrTIB9pffNhQTG#Ec-+qUa@R
ih8lVcpI"b2afqVV))*&,i624qZpqrI8V1+Uied%0rR&e3,Yd!Vd,EF4GaaZac)4
$#2q(949J'*YY2C*0P&h%99[,*d8eTKAd9e%)(H0e0I@#iYIrZjCcc1jrfdIhrpr
CYEp#-lMEAY+2aZ[S91-*+*Gcb1KHG2Tqd*!!VI!-qHmkIrqf!CZ`'Ie!CCJ-`3'
G%"PC3kF%i*E,%G0m-@9C&`ShimbZjR&pANa[8TD`&@p+1!41++!4FP$!)Q&"'B!
Dl&5hKr$Y0C2c+lEF+0je12q,9Eb0q(9@m2'[VI3SIRLp`!hrk,h8NeT[S+cMDZh
KLf['[U&4(l29)ZfdHPMaiVUEa6RH,B$(JkIIJN1#b!r[-!3'%)`[@mJDf@&hH&$
J`B(ZLepSfm(jJ15,"f$hpKjrmH2T&[T&[pRPhJi0rfje'S)6Gb&&UKZ104bRrd!
*MA8&1P[4PP2&eN5cTrhA$qDK"6m[TA8!jT02'VS+H9IJ%X)+I!q)!R(!)1RA`!F
m$838mRRJ%r)!6*!!#!8bBm&2IJ8hri!#CJ"*J"+b#R6pi!R'!*[3#E1#RND!"!S
-MlS"!+C'XJTllT!!"15!6c!#6`#@F&2(q%!RUJ%c`#6J#"38JS+3!&"j3@RP@i"
!+IDpZ#Ri3Cc`J+H&F`8r"#Jb`P-Vq)"2bJ%i5h3m(p!"20!)(Bm%+6K"5F)1*`J
H!RTm)*!!m$QJ%$1H!'Fm!)M[qJ!3%RIm-!Q'!32j8q3!J@P3#P30K8#-c`M-m0K
RKr-m0KRKr-i#QF'`cJ+C`JKR!8cIC!)&"QK'CS8("%MR"$8F%24`3FF%-*Q"K-`
%QB'%c!5CBK"PK[-[LJ%`eZKpS3`qeL!%XS+INr+!3-"j2NJ%$+H5'8mJ-"j!&2)
$!H3%jj!!'!mF(RMK%H2[!#438q)(JiJH$L#9cL#-(%"*`a)T`r4!)%j`lD#Ri`I
$aK'$aZ%!3*caJ5H+)QH+#6aGm!30*pN0*pN0*pN*cl1#!3-"iJ*2%p-!J9RLDf#
RiB4(KK%H'%4iB4(KK%H&c@A3&"01L"qL%24jB""#ZL',SLF1L#1L),d3Nk)GHL*
Ak)Kh4#6SKqk)FHMd3#"Kk)Q$T#Q5NCX`Sk3KA5&)p)4lT#&G)-h5$pdJfp)1r5$
0dK1I5%Bk3J(5%ip)f)"$1N'RT#DqN!"dk3MR5%%k@l!)(6mS,Mb`'HB&CjBLAj3
E$b[4&R!+M(VY,Z+1IIC1Ahf,Na4#S8APJmjf5r5r9h9m33JJkQX*UAYpKEpU-TS
"SZEZU1EPcI"ck1GcS)!FkeA5[N'kT)K4GIM(ClJVY+b9a4H100N#RY[f8GSbSlZ
$UL$4FhFBf,PBHAK8FqTQj38a8jjD*fA*'N5Tp)bTl#ZF&m6,RFYjFkE"Tb$-+XY
6cQ(125@N(CR#R&aYKcT+bYKcZ5mZGH3@*"JSmr0b-V([H$8aFRR%F8TrbSkfHP5
U0+Y89V4JT8HUmULFL'djK8Ap(+amrI03f2-hN!"fT3Tc@!c$CS[%0P+[M[+V[81
RHX+[EiZIM"9,G-Fhi+qY5V+ek1QJ`"@93RU%ZLSeM+SfN!"eC"NcfBG(0i%r&bY
lNd84L,TRkXC#+NB4fPfA6P1THa-5RFTHda1`Yc5[X,H,QcF[,bF2,$8VTA1p4)d
b92TQU9f5YQHa2@"HkMPS8FZ,QhqAPBlXSccjj%T+MP0+0NV4&NU01kbk+29-U1i
JVb$4FfK8i'(Pck2#9-!9'HLI)VdU1[@SaVrT+dbq&4ThXAZSjL&(-8SdZ+`Sce@
"a*8+1`FU0$LX3T6[N[H&1a4#RBaFh"aFjLT4K4RXN501P4kGU&,*@bSdlb,h8Hb
0VMBE)+2,b-V28j!!T4RFTN@+9(BY@Z&PE#M6f1AZSqd3ihD4Fh#Sic#LB8BbT$K
pkT+NkTTaf5aQSP2C5He41`fCU*f'c+N1EVKjBJ1&0RjUP3Gr[f4HS3U03e85dB+
Fa2D[HlQ)[Dl!AY3c@(PQRKEQ$X6M0%kY+NkYTc'5aQ+DH!KlU5DK5(2,*`DH9U3
piH4U8U28Z9'5YQMa2e`2HMbm44iR2,`mX8,"4(jHLSjb)VpBP5GBe4k`@,Sp6h1
AZimj%l5FmF53!"QdCRD2r#C"l6B8GNid8Q5Y6MP'eMhFDhPPaVF@b,h[mA*[H&Q
'GKKaMj-kdP-KK[f#90Tm[-R[,1LGY@8l-(V3!-'rSj@p[-A0hZhSjfGLiicY%U8
jfjmTSF*!+9+V1hVhBc6#k&jaRE#p4,UR4+1,['%,93Z(MX+"qJP8I3Fbl%XBLP#
hM2@T0SK5-D)bV%DP*l+-Qh@T8R@Zf60"Ba86#hM)CU*Pfj`qbaSIhe(2fQ44bGl
0m(DcZG"4aN`c4jBT(A*8rA0BIA"HQH%UY['JcJ9Pl!i&CH`F+ZKLm"R!UMcK5,0
+VXfX#VUAX+Y['QY9bi033Cd9D,'UP@M'Rp&+VqLY9kCd,fC!AR'R,Z%5!Lrd0Bp
U3&P9Ra*508P9kTaNqGj!AR'Y,Q)N"46'lb!rJ4l*G@P@DYU3!#G6"K@0ieeUcBS
N#&CE4iiN#(Mm&5Kml`9JmAl-JESB44$NH#VZ&ja`5d9U5a@Sa*rKh[1JGF852+$
)qNPAr5DZ",-f,+EH1KDVl4#V&EM$6P9U8D-G&SP4fMM0P@Se6)Yik&c)SVEPLYZ
E4amM+a0aPe-VHXA"5TdBl1[5Tq[DVDD,e18mil*D+fTBVD[FVHXU95M4MXeL9(V
'XaaNVCTEEaf,FUl3j3f$d55j0("a8FKMZVj5Rb8Cr(B*9(B01@dB+9$H2&DSQS9
!`JJia-+MR$eKR6jC9"r5f4DT8pUkUGJ["82a5KEak@E+R[)0-3BDS1ARj&,`85m
$VAMf$R8HqQP3I6C8&C9T+')9Yik&Z(13!1'F(Zqbr!RhPhNdFdk#-&dT`cl8rH#
Z3T!!rp!Cef9Q#P3hMX@U%E!-Xk1i[jclbplqLF8d#,5K9!r)3+cX8UJq[*P8,-&
&Caip@0Ir5cFR,aYrYm[[k+,JaUZ6m!h4JlCKJlLhJXL$*B2Fj'9[F[`&iD`JCL2
ic0`lXNX2f6,$kM6[3dCcHNr'alA$VK'KhF$3lfQEPj@I1bmC+%CcHMlaj(e%Urk
M@EbkPl#VQ2+VPS9Bd1paRiZ0[cG`9mQ+P@R0peU9BFR61G+k'$&`iP,l@K,Li0`
ki1aY4m$%DG-aI40CfD92fE9`jC@`jjY8[$Rc$H)Z"SD#aDi8c$RS["Dj+RecVJ+
D96&J3iRRfSFZ0LF"9`0$1mbF[1SXUT&SFUY(bJDp+Vel@!T`AV`&(Nq2$VE*%C4
SC6mMHdCpjJiZ64cdEU+P@MD,2rK3UcaH@)b1TH`UccbAK9pSK9SqJl(b-l2SjZ*
ZG[4bUL&@GLG2q32ISN)`M@k-)aXrZPLJXamU0C8rhm'T(q60B4QM"RNJ(l6(MH5
4K'Ya"6#UC5HN![Q0I%9&9*8p8e1DXVL(Sq&A8Bj!C'`59E"U(6Urd5X63J$'28-
H)IE0%ri`'M#,LERDK9BH3FQ5S!aKfMKQ@R`[KB5hA'1X`BQ9M(U)[#Xl9%DMY@)
cP(-bXBj"*&`P9h$LVPd,eDpXBimAfelELlJk`JdA0a0cGj2JB[JjaZrcmM('"qi
Z%h4)ab%5$EV#[!JaG$X(*QQR-V-j!AM1hQ`I3)-9R2a4AS)QCY6-clc,hUG8%V-
j'*'a5XpLYCf,pM0KCR)Dm,1m4HU'$%YRNjIJB9'pbXr0aFV''$aKCR**)f59RXQ
Ve,d-f,BNBj(ALf)M#4F$#3R61h0l[FK'%Lh656'16#4fL9IfMddr8&kE&NBlKVa
RFSjIe`-)jddQ&+T4R*A)4SS`R'SkDIU#YME3M()`m64l3lD&`1Al2[0cPjZpQjY
(&hq$QjH-&6RBUU%YiMj"He5V1eDfdABd96pZha6p-YcCUQ$%[JMkkXr$[@1$*LR
ij2j(E*9IE0@DA3[CXdiEbUdBMTLGSQmhe('hk1L%Zc5FS8MkU9Ap9efL@LpK9RF
MH&@M%G-1)jl+ZHLd`MT[`SZaYE'EK@+RmEbXXcq6%E48`BMYTPj[!aFrFBfENCJ
QBacpQ49Kd+pl"pC+XqXe@#i-'I!6'EbSV9Na#X1dALpq+r'&BM8G+X2'0[i2VT9
Reh(-hD-'F&XCjbT6%AaCJ[LL)'"he-G,p2-fBN%6pARET9REZZN)X`CTfEbT-dl
60NDGTLGSY*i`lF&[X&,"'9SljB9j`K-8kZaQTAYjAPUrY%+p1dHl+rHiLPH0Yd5
(hD9KGZQlXk'LT#fmXDj#d9Rc"@IH$C'ceB1eGCBUa'@1DP9c@T!!Td,fBl21@1B
LXkB+cK"G4dRk'"p53QHM$`6LK+m5V,aeXc0'%69TNh9fmYM0eHCGR'(-6YBphLU
@#VUir%N,3f33X$f6QZH%SXBTkM[0250UfBHlFJil[&bDKS-aYqT8&0HM"HT9&kk
E!6*JV@12EdH&3MeI6"IpZqqbmeFbqE`&FH!m"XMD*8qdD8l4HVZ*RYl2Y`Y6*al
LN`AmEl,B8L+D5SqJLQfq5T,jVKDB,'H&U(jAQ+pkL+k1#bMQ-+C5Nq4&-4fM!T!
!A6QZ&YJXBidje4ALHrD)TD&qm5RSf#Vc0aI!9iE6Q3ra#9q'$DT9'eGFb9CJcbU
IKI%@pMEQ,Ha&q[$cFA'SXaE4bU6H%rLmmDG(PHYaDc#j6lrerGF9Y)-r`D51eLl
C+fH19chP4l0#M6VDZ9(c5RT#9()FIBfk+-&98M*AYNP@fDRKDI926"UMNV(2+V)
r!aFKAm!&!MTX#9mi(iqMSJ)G['eHm)cJ(XMjqEV[cQ(i$"Q093p-QPdT+Y%H)cd
[HfrNM[`!1dhFlM$`X1"2Ld"k$4RhFe3b&$)Gh#PCh$5X"8ak`a+j`J@EiHqj#Jp
,hVrqT"##-+5pa--+4Je5T%5-(V0p8BZDBrqDdNSHMma$4XHae*VHV6@hmNJMm0m
pNdENY@0i`@c)ZDG+&p9-2UTKp9-2UTKp9-2UTKp9-2UTKp9-1DQ!6fElBAbJ`Ab
HU-NaE!UGdS@1A+XM)k&R59r*0HIMND,Q#3mL!NKC)86)q#0HI1CiVC+F&BRR4r6
0HIpbRdI-%Tq58NTk&aQN21pVcX(Q89bbCLTc`#(b*9i`'ShPQ#8j6b5Q4EQ!%24
LVch%1qD*6eE#5eB)IE!)I2RApm#Ad'f8dJ)H@!3rr"eqB#AP0NSai"d8ZVAq+#A
q64,ZP%ZP3KLMJ5qDVMkX%TrdX5@5KN#c!*I[JPTY%TUL*,@SGS[%#8&dEeQf8VN
3N640ArQ",qpSP2dLNPdb*,Nb8eipXp8Gmec#JbmMLNSh8Uri!5Q*EQ@'[6eC8GH
1[%SY9i6D+'U3!'liMpADrjJ5qSh,$T`3Q5N"pKS!NriD*$eI55@)*0m#3LmU%3e
MRjLf#Br1@5BrjSG[FZV+(D6JMQ*MPP6rH@)VYCbS4iY)rh'f@2pDB+TlT3i9S)r
ZYNaq1icJ8Ge'9#11Y)NYNaq(*XpPJT3qi5"&U0c5)'`([A6hm*82H!Q1l1j*Kqq
BrGNll**KjTT([Y[)2fe(l0TqiL9$i3*ZSh$!IVS2e@6ieT3p6N&@iSMS+*KDM(Z
46pmNU(l`*R%-'%B2dU(k'*mddSIQc"9QP0c!SIR+2c(6k-j82V33D3N,PC!!r*m
IN!!Tr!'8A)dRGYS`CUip[DI89+Kpm%hhQLBZS5BHe!ZdMeVbKSa`D6ifbBHa-qX
0(YJP3rm$d3QaNjXaMeT"A*r,'814,"@Gid6'DSN`rr9$G*p`FU-,HYBiZ`qFSQ(
U6%"NrXV+'cG"T6RaX%aL35B82#4*2[QP4JdfP-U6PC!!r"J4H6r1mSr6RT6*!`6
(8P*-Ia20+4ZDbS`jr'P2`9A2!@!U`8$dY$d5TrYZ80`+$5rf9SJk9fcBKHB(RE0
#"+Ye""*#JG#SqYNP3mh"XL#Q!P3IL6hlX9-5V(*!33jSmU-#D5-dad+MpLK+Kpr
)qpmijL9$[aeZ%l&4Sb*82*i2)mF["+[3"9kMX9-5a$apMaZR8'*8++UdA3(3UBN
d1@!CfD1AA+MIkJUqGf+Q*4"i+Ki#%I+CAa[d!N2Q,F&,&@Sqf-ID+HFF8RlS*4Q
#Zkp(IL(I%21d*8-$eF,iVS9-AX6h4a"Y(3pP4[M",q9lP3i9"hXMUXNUk)*4B(G
#TLi'1m@1l5RFXP93iP@Q1@9`9-9[$ZM$Z@(G'*80!l6#D9h+MdGKbR"Z'NU'C2T
MI#HXjBqXXF&Tk8"+JZY-*2AH4!F"3lGKl*!!5S"fQrhHk8(E*00+1fl+UKH4P((
XpCS6djcZp)ZQeAGJUF[ia,Z1b+1*NIRk*8(FP#RGh5JU,(BP6pMXUUc39(&'pA5
(B"(qSdrE9+UKFaP(*@p5Sp5X@(8H%199HF#SkQEe+KepKef%q+#99#LQ[BeF(,8
#Ymh+8H6f81)A"ARPH2@d+0h-ETUI-Y+UKSaelQ8jM1j-KJNX(9@*9l3+MaE("8a
S`MUhMUUTr!@99$k1l!iIAVBH1V++3)b,ZY9r)&4mIVe+KX`$C'JM)Zme3K&B#9*
hSJ2%Pq)&5,[Y9e!9#bXlcQ$BS1M2'4GrML!eJjYfX*3FQ'U-bL*SSiaCf$Pr%EB
q5#XFl8cKM6%*@,a@RFclSjV%DH#`re1"h&')6H!%KT`EbYj0BB@fBqCH9ZX#JGr
V`Vc!RASZ+q91Zm-m(2UAQ&HRS$rQR*!!Mf0apMElJ"([l@K1'Lj"qqIGlJbhr'1
G@4Mjjde(39kQ)#N+D6H80SC$p6Z0VZM'ZdlJ()#0GZEr!%am)XrMRq`GKZi1qqj
J`4J'$jd5*DI2!PI`3k1MU),2M!-&@C',2+!C2393@HDAH3&H1"B*JKQSZJ'$-,)
CYpi!c%6X2@AK!-'$C"Kj3$,05'16L3N,1)G3Ak!)Xm"3a9GImB$"Lm)aer4!B,U
+'f`3'F+4`0rLll*KPJ#3!d%#I9i!!J!,5(P`CA*B3feN,QJ"!*!$#&4&@&4,38K
-Sma3eU3+QQ`"!&#F*FB!"!#3"LME!*!'#r!,5(P`CA*B6'PL,VN"!!!,q&"56dT
,38K-SmY9$+2-80d"!+RTA$-!!J!!B`i!N!BI[3#3"&!i!!!:










Path: ucivax!gateway
From: [e-mail]
Subject: Re: Getting a PixMap
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 57
Date: 21 Mar 91 23:08:59 GMT


>Quickdraw.  The Inside Mac does not describe any more than one pixelType for a
>PixMap (that is Chunky, pixelType=1).  The pixelType on this device is 16.  Wh
>at
>does that correspond to?
>

According to 'Designing Cards and Drivers for the Macintosh Family' page 130,
the pixelType for a direct device is ChunkyDirect == 16.

>Second, I have a question concerning 32-bit addresses.  The baseAddress of the
>PixMap for the 364 board is shown by the THINK-C debugger to be 0x000000, even
>though as a long int it is 0xFA000000.  (The same for the main screen--the add
>ress
>is listed as 0x000000, but coerced to be a long, it shows up as 0xF9000000.)
>I
>assume that this is just a sign that THINK-C is using 24 bit addressing.  I am
> also
>then assuming that 32-bit Qucikdraw will be smart enough to use 32-bit
>addressing when I do a CopyBits.
>

I am having exactly the same problems with 32bqd installed, Think C 4.0.2.
As I said before, if you get any useful replies to the question of how to
write directly to the PixMap, please forward them to me.

>My last questions concerns the color version of CopyBits.  Do the PixMaps used
>in CopyBits have to be the portPixMap of some cGrafPort?  I would like to be a
>ble to
>copy from the PixMap associated with the screen to some PixMap created in main
>memory without having to create any intermediate CGrafPort's, but I don't see
>how
>CopyBits will know it is a PixMapHandle and not a BitMap without the high bits
> set in
>the portVersion variable.
>

It works fine for me - just remember to lock the PixMap before you try to
CopyBits from or draw to it.  CopyBits copies from a BitMap to a BitMap -
whether the BitMaps are associated with GrafPorts or not is irrelevant.  The
same goes for PixMaps.

>What I would really like to do is get around all of this foolishness and
>directly access the bytes in the PixMap data on the card, but the 32-bit addre
>ssing
>seems to be getting in the way.  Any hints or ideas?
>

Me too, but I can't get SwapMMUMode to work.


Mike.
_____________________________________________________________________________
Michael A. Kelly                                   America Online: Michael792
[e-mail]                                  Compu$erve: 73567,1651
_____________________________________________________________________________
"The proof is left as an exercise for the reader."










Path: ucivax!gateway
From: [e-mail]
Subject: Re: _SwapMMUMode doesn't work
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 65
Date: 22 Mar 91 00:52:51 GMT


This is from Juri Munkki:

I found out what is wrong with the whole thing. I did some work with TMON
and I came up with the following information:

Think C has incorrect glue for GetMMUMode. Actually the glue code is quite
much ok, but the call parameters are defined wrong. The glue code expects
a var parameter just as is defined in IM-V-592, but the compiler doesn't
allow this.

The glue code for SwapMMUMode wants a char var parameter.

So, you can't use GetMMUMode to get the mode, but then again you do not
need to, since it is given to you by SwapMMUMode. Here's the shortest
application that works and at the same time documents that it works:

void    main()
{
        char    mode1,mode2;

        mode1=true32b;
        SwapMMUMode(&mode1);
        mode2=mode1;
        SwapMMUMode(&mode2);
        Debugger();
}

At the Debugger() line, mode1==0 and mode2==1. This is as it should be.

Happy hacking. I'm going to bed.

   ____________________________________________________________________________
  / Juri Munkki     /  Helsinki University of Technology   /  Wind  / Project /
 / [e-mail]  /  Computing Center Macintosh Support  /  Surf  /  STORM  /
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

P.S. You might want to report this to the Think C list. I'm too tired.




I managed to get my code working before I received the above message from
Juri.  Here is what I've got:

    short        mode;

    if ( QD32Installed() ) {
        SwapMMUMode( &mode );
        Debugger();
    }

When MacsBug is invoked with 'Debugger()', it says I'm in 32-bit mode.  Yay!

BTW, if the above code is run with the Think Debugger running in the background
it will crash and burn, which is what was happening to me before.


Mike.
_____________________________________________________________________________
Michael A. Kelly                                   America Online: Michael792
[e-mail]                                  Compu$erve: 73567,1651
_____________________________________________________________________________
"That's not a lie, it's a terminological inexactitude."
        - Alexander Haig










Path: ucivax!gateway
From: [e-mail]
Subject: Re: _SwapMMUMode doesn't work
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 22 Mar 91 00:53:19 GMT


A correction to my previous posting - my code should read:

        short           mode = 0x0101;

        if ( QD32Installed() ) {
                SwapMMUMode( &mode );
                Debugger();
        }



Mike.
_____________________________________________________________________________
Michael A. Kelly                                   America Online: Michael792
[e-mail]                                  Compu$erve: 73567,1651
_____________________________________________________________________________
"Television validates existence."
        - Calvin










Path: ucivax!gateway
From: [e-mail] (Ta-Chun Lin)
Subject: Traffic watch
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 28 Mar 91 18:04:41 GMT

Hi Everydoby:
  Did anybody use "Traffic Watch" before? It is a counter to check every
packet send out and receive to every node in a network system. It turns
AppleTalk off and uses Printer port instead. I do not have idea how it can
be implemented. I use dumpcode to disassembly "Traffic Watch" but I did not
see any useful Toolbox Routines Call. Does anybody have any idea about
how it is done? Any suggestion is appreciated. Thanks in advance.

Shiem-MIn Chen
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Lars Petrus)
Subject: New Creator
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 41
Date: 29 Mar 91 09:49:24 GMT

   I need to change the creator and type of my documents. After a full day of
trying to understand the crazy world of the File Manager I thought I had
grasped the nescessary concepts and came up with this simple solution (as
you see, I work in TCL):


Boolean CLogoCorrectorDoc::DoSave(void)

{
    OSErr        theError;
    FInfo        *info;

    theError = itsFile->Open(fsRdWrPerm);

    <save the document>

/*    theError=HGetFInfo(itsFile->volNum, itsFile->dirID, itsFile->name, info);
 *    info->fdType='THIS';
 *    info->fdCreator='THAT';
 *    theError=HSetFInfo(itsFile->volNum, itsFile->dirID, itsFile->name, info);
 */
    /* wd=macSFReply->vRefNum; set in OpenFile() */
    theError=GetFInfo(itsFile->name, wd, info);
    info->fdType='THIS';
    info->fdCreator='THAT';
    theError=SetFInfo(itsFile->name, wd, info);

    <do some cleaning up>
}

   However, inside GetFInfo() (or in HGetFInfo() if I use the equivalent
commented code) it just dies in a Bus Error. I'm absolutely clueless! If no
one can help me I guess I'll just have to delete the file and recreate it...



"Madness is the first sign of dandruff" |   Email:   [e-mail]
   - Dr Winston O'Boogie                |   Reality: Lars Petrus, Solna, Sweden













Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: New Creator
Message-ID: <[e-mail]>
In-Reply-To: Lars Petrus's message of 29 Mar 91 09:49:24 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 26
Date: 29 Mar 91 14:21:27 GMT

   Boolean CLogoCorrectorDoc::DoSave(void)
   {
       OSErr        theError;
       FInfo        *info;

       theError=GetFInfo(itsFile->name, wd, info);
   }

      However, inside GetFInfo() (or in HGetFInfo() if I use the equivalent
   commented code) it just dies in a Bus Error.

You must allocate space for the FInfo record before you use it.  The
easiest way to accomplish this is to use stack alloation, ie, to
declare your record locally.  Try:

{
    FInfo info;

    theError = GetFInfo(itsFile->name, wd, &info);
}

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Martin Minow 31-Mar-1991 1031)
Subject: Buglet in TBUtilities.c PositionDialog()
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 28
Date: 31 Mar 91 15:45:23 GMT

There's a minor bug in the TCL TBUtilities.c PositionDialog that doesn't
correctly position tall dialogs (270 pixels) on small (Mac/SE) screens.
Make the following changes (this is being retyped, so fix any typos, too :-)

    ...
    left = (screenBits.bounds.right - (theRect->right - theRect->left)) / 2;
#if 0 /* Remove the following */
    top = (screenBits.bounds.bottom - (theRect->bottom - theRect->top)) / 3;
    top = Max(top, GetMBarHeight() + 1);
#else /* Insert the following */
    top = (
        screenBits.bounds.bottom
        - GetMBarHeight()
        - 1
        - (theRect->bottom - theRect->top)
    ) / 3;
    if (top < 0)
        top = 0;
    top += (GetMBarHeight() + 1);
#endif
    theRect->right += left - theRect->left;
    ...

Note: the same error (with the same fix) is probably in FindDlogPosition
in the same file.

Martin
[e-mail]